-
Notifications
You must be signed in to change notification settings - Fork 580
fix: adding length validation on deserialization #19415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
c73a4ea to
b6cc9cb
Compare
PhilWindle
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just one thing we need to check.
| const reader = BufferReader.asReader(buffer); | ||
| return new StatusMessage( | ||
| reader.readString(), // compressedComponentsVersion | ||
| reader.readString(MAX_VERSION_STRING_LENGTH), // compressedComponentsVersion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just check this? This version isn't a semver (i.e. 1.2.3-alpha.123). It's our compressed components version which incorporates a number of items. Can you verify that MAX_VERSION_STRING_LENGTH is sufficient for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is an example:
p2p:7:libp2p_service:libp2p_service Started libp2p service with protocol version 00-31337-00000000-0-14d6d44e-01eff751
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should be fine as MAX_VERSION_STRING_LENGTH is 64, but would like to check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PhilWindle 64 seems to be enough for MAX_VERSION_STRING_LENGTH looking at how the version string is created:
return [
'00',
versions.l1ChainId,
versions.l1RollupAddress.toString().slice(2, 10),
versions.rollupVersion,
versions.l2ProtocolContractsHash.toString().slice(2, 10),
versions.l2CircuitsVkTreeRoot.toString().slice(2, 10),
].join('-');
64 seems to be 2x as long as expected length
Flakey Tests🤖 says: This CI run detected 2 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
4e795d8 to
3e72988
Compare
3e72988 to
11f73b1
Compare
11f73b1 to
994b779
Compare
Summary
Add semantic validation to P2P message deserialization to reject protocol-violating array/string lengths. This prevents DoS attacks via maliciously crafted messages that specify enormous sizes, which could cause memory exhaustion before the buffer range check catches the issue.
Changes
Foundation Layer
maxSizeparameter toreadVector(),readBuffer(), andreadString()methods. This is a non-breaking change - all 161+ existing calls continue to work unchanged.Constants Organization
stdlib/deserialization: New module with shared constants:
MAX_TXS_PER_BLOCK= 2 ** 16 (65536)MAX_COMMITTEE_SIZE = 2,048(theoretical max from bitmap design: 256 bytes × 8 bits)MAX_BLOCKS_PER_CHECKPOINT = 72MAX_TX_EFFECTS_PER_BODY = BLOBS_PER_CHECKPOINT * FIELDS_PER_BLOBMAX_BLOCK_HASH_STRING_LENGTH = 128p2p/reqresp/constants: P2P-specific constants:
MAX_VERSION_STRING_LENGTH = 64MAX_BLOCK_HASH_STRING_LENGTH = 128MAX_TXS_PER_BLOCKfrom stdlibBounds Checking Added To
BlockProposal.fromBufferSignedTxs.fromBufferCheckpointProposal.fromBufferCheckpoint.fromBufferPublishedCheckpoint.fromBufferBody.fromBufferCheckpointedL2Block.fromBufferPublishedL2Block.fromBufferdeserializeValidateBlockResultStatusMessage.fromBufferBitVector.fromBufferTests
BufferReadermaxSize bounds checkingBitVectorbounds validationFixes A-273